Day27—補充：API典型風險

2025 iThome 鐵人賽

DAY 27

Security

資安小白—30天學習滲透測試with OWASP ZAP (Zed Attack Proxy)系列第 27 篇

17th鐵人賽

姐姐恩

2025-09-08 23:56:24

81 瀏覽

分享至

大家好！我目前正在就讀資訊類科系，平常以接觸程式撰寫居多，對於資安領域的技術沒有太多了解因此希望藉由這30天的機會，以OWASP ZAP作為主要工具，從實際操作和分析，從環境架設、基本掃描到進階弱點發掘，一步步建立資安思維。
　　我將學習如何利用ZAP自動化及主動/被動掃描常見的資安漏洞，並理解其背後的原理，以及該如何修復，例如SQL Injection、XSS等，讓我從「資安小白」進化成具備基本滲透測試技能的「資安入門者」。

今日內容概要：

API的典型風險
OAuth2、OIDC與JWT的安全陷阱

API的典型風險

API作為現代應用程式和微服務架構的基礎，可以說是資料交換與業務邏輯的門戶，但也因此成為攻擊者鎖定的主要目標。API的典型風險主要圍繞在 授權、資源管理與資料暴露 這三大面向，其中最關鍵的是OWASP API Security Top 10(2023年)中名列前茅的項目，本篇文章將以「授權與存取控制缺陷 (Authorization & Access Control Flaws)」、「認證機制缺陷與 Token 相關風險」、「資源與效率管理風險」三種風險類型介紹。

補充：
業務邏輯： 指一個企業或系統為了達成其業務目標，所必須遵循的一系列規則、流程和條件。它定義了如何處理資料、進行計算、驗證資料，以及在不同部分之間如何互動，是系統的核心部分。

授權與存取控制缺陷 (Authorization & Access Control Flaws)

名稱	OWASP排名(以2023年公布為準)	風險	舉例說明
破壞物件級別授權 (Broken Object Level Authorization, BOLA)	API1	API端點通常會接收一個物件ID(例如用戶ID、訂單ID或檔案ID)作為參數。如果伺服器未能驗證發出請求的用戶是否擁有存取該特定ID對應物件的權限，攻擊者只需簡單地修改ID參數，即可越權存取或修改其他用戶的資料。	請求`/api/v1/users/A`應回傳用戶A的資料。若攻擊者將ID改為`/api/v1/users/B`且成功獲取，就是所謂BOLA漏洞。
破壞功能級別授權 (Broken Function Level Authorization, BFLA)	API5	應用程式的權限控制邏輯在不同用戶角色（如管理員、普通用戶、訪客）之間界線不清。攻擊者可利用這個缺陷，存取或執行他們不應有權限的功能或管理端點。	普通用戶嘗試存取管理員專屬的端點，例如`/api/v1/admin/user-management`，且伺服器缺乏適當的角色檢查。
破壞物件屬性級別授權 (Broken Object Property Level Authorization)	API3	1. 過度資料暴露 (Excessive Data Exposure)：開發者依賴前端去過濾，讓API返回了過多的物件屬性，然而前端並不需要這些資料，如密碼雜湊值、內部資料庫ID等，攻擊者也可以攔截未過濾的原始回應，有機會獲取敏感資訊。2. 大量賦值(Mass Assignment)： API允許客戶端在單一請求中修改過多的物件屬性，使攻擊者有機會在請求中注入不應由用戶修改的屬性，如`isAdmin: true`或`account_balance: 99999`，如果後端未做白名單驗證，就會導致權限提升或資料竄改。

補充：
白名單： 指一份明確列出被授權或認可的項目清單，只有列在清單上的實體才能被允許，而其他所有未在清單上的項目則會被拒絕。

認證機制缺陷與 Token 相關風險

名稱	OWASP排名(以2023年公布為準)	風險	舉例說明
破壞認證機制 (Broken Authentication)	API2	認證與會話管理機制的弱點，讓攻擊者能夠冒充合法用戶。	1. Token處理不當：使用過期或不安全的 OAuth2/JWT流程（如已棄用的Implicit Flow），導致Access Token洩露。2. Token驗證缺失：伺服器未能正確驗證 JWT 簽章，或是錯誤地接受`alg:none` 等不安全的演算法。3. 暴力破解或弱密碼：缺乏防禦機制，讓攻擊者可猜測密碼或Token。

資源與效率管理風險

名稱	OWASP排名(以2023年公布為準)	風險	舉例說明
無限制的資源耗用 (Unrestricted Resource Consumption)	API4	API未對資源使用設定限制，讓攻擊者可以透過單一或數個請求大量消耗伺服器的 CPU、記憶體、網路頻寬或儲存空間。	1.缺乏速率限制 (Rate Limiting)：沒有限制用戶在特定時間內的請求次數。2. GraphQL 深度或複雜度未限制：允許發送過度巢狀(Nested)或需要大量計算的查詢，導致伺服器崩潰。